NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/hardware-part1/2785

Internet Message Format | 1996-08-05 | 9.4 KB

Path: sdd.hp.com!inn
From: Jeff Grimmett <[e-mail]>
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 SCSI
Date: 28 Jan 1996 18:43:03 GMT
Organization: Hewlett-Packard Company
Message-ID: <4egg3n$[e-mail]>
References: <4crkgh$[e-mail]> <4djffa$[e-mail]> <4dlre0$[e-mail]> <4e0amr$[e-mail]> <4e0jru$[e-mail]> <[e-mail]> <4e8f8h$[e-mail]> <[e-mail]>
NNTP-Posting-Host: hpsdv330.sdd.hp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

[e-mail] (Dale Currie) wrote:

>> >Hmmm, Jeff, whoever wrote that technical bulletin was definitely OTL.  The
>> >A3000 manual is quite clear about removing all terminations EXCEPT the last
>> >drive on each end, and that is _normally_ the correct procedure.
                                 ^^^^^^^^^^^^
>> Allow me to fill you in on a dark secret of the manufacturing industry:
>> technical manuals are USUALLY not synchronized with what's actually

>Agreed! That's no secret to me after having spent many years in the
>technical, engineering and computer ends of the communications industry,
>where hardware is changed almost faster than you can count revisions. ;-)
>
>Nevertheless, in this instance, the above statement is correct as stands,
>and applies to all standard SCSI systems.

OK, read my post to Warren.  I don't know WHO is responsible, but I want
to dispel the illusion that we're talking about a _standard_ SCSI system.
If it were standard, the need for the technical bulletin would not be
evident, neh?

If the A3000 early revision motherboard were standard, I do not believe
we would be having this conversation.  I am speaking of a specific case,
here, not SCSI in general, and I appologize if I have in any way given
that impression.

>> The original A3000 was released as revision 7.4, or thereabouts.  Within
>> six months of this, they were at revision 9.0.  7.x (I'm hesitant to nail
>> it down to 7.4 as it's been a LONG time) had some fairly FATAL flaws in
>> it, including one around the SCSI circuits that caused it to have
>> problems with my "new" Fujitsu drive (225 for 105 megs, not a bad deal
>> back then).
>
>Interesting, I didn't realize they changed that fast, as it took a little
>longer than that for them to filter through the chain.  I have a 7.3 which
>has no problems I've found yet, other than possible Z-III defects in the
>daughter board that I have not had time or need to check out.  What were
>the SCSI problems you found?  I also have a 9.02 which has most of my
>external drives in a large tower case.  We have a number of others in the
>group, but I don't know what revisions they are offhand.  Note that I have
>replaced the controller chip on them to get rid of the reselection bugs.

7.3, eh?  You must have bought BEFORE power-up, or else mine was 7.3 (no
way to find out, it went back to CBM the same day my rev 9 arrived).

My impression is that the 3000 was pushed to market a bit too fast.
There are a lot of indications.  It was released before the OS was
complete -- thus the original 2.01 KS/WD disks, the 1.4 beta ROMS, and
the softkick (IMO, I like it, but they didn't see it that way).  The
minitower on many of the earlier models was wired backwards.  The rom
sockets were in many early models labeled backwards.

Every indication I get from this is that the rev 9 motherboard was well
into pre-manufacturing stage by the time the 7.x board hit the streets,
but not yet ready to be manufactured.  I do not think they released the
7.x motherboard, took a break, then set out to redesign the board and got
it through the entire process in the first six months of the machine's
availability.


>> Knowing this, don't you think that maybe a technical bulletin written
>> AFTER the release of the 9.0 motherboards JUST MIGHT be more in synch
>> with reality than a technical manual written over a year before that,
>> based on prototype hardware?  I know where I'd place MY bet!

>Possibly, but not necessarily.  In my experience, it depends on whether
>the person writing it knows what they're doing or is just regurgitating
>what they've been fed.  :-)  Production changes are sometimes made for
>reasons that may not be technically correct, and C= certainly did that on
>more than one occasion.  They would have to keep track of all changes and
>combinations of drives used, etc., then document them all and the effects
>of each.  It doesn't seem as though they did a very good job of that.

What I've seen indicates that they came from one or two points at CATS,
not several disassociated engineers in several different places.  If they
had a clear chain of command there, it would be not too difficult to
filter all changes back to one location for centralized documentation.
All this proves nothing, of course, and is based solely on what I've
experienced -- I don't care to try to reverse-engineer the process, as
I'd end up filtering it through what I consider the correct process.


>> >True, it is one of the most tolerant controllers for this, but that will
>>
>> Point of order: name some models.  I have recently successfully
>> interfaced with two of what I consider "new fast drives" with absolutely
>> no problems at all, other than those caused by my own stupidity.

>Lt730's, SQ105's and some Maxtors come to mind as being a little picky
>about bus noise and proper termination, particularly the latter 2.  There
>are no doubt others, and running it in syncronous mode will usually make
>any deficiencies obvious fairly quickly.

I've got two Maxtors at home, neither seems to object :-)  As for sync
mode, let me point out that the A3000's SCSI controller does not meet
spec for sync transfer mode.  You can either enable all, or none.  If ONE
drive on your bus does not properly support it, you'll have problems,
more than likely.

>> >Wrong, there is nothing non-spec about it, other than the bugs in the
>> >original controller chips.  The design is essentially the same as a 2091
>>
>> You don't consider bugs in the hardware to be a non-spec issue?
>> Personally, anything that takes it out of spec is by definition a bug
>> unless the designer intended to take it out of spec.  Did they?  I doubt
>> it.

>Ah well, I was referring to the design, not goofups in the assembly, but
>there certainly were some of those.  From the discussions I've seen here
>over the years, it looks like some of these abberations have a regional
>basis to them, possibly due to the way they were batched for shipping.

A very distinct possibility that I won't deny at all. I feel maybe
perhaps I didn't give the right example, though.  I wasn't intending to
say that "only manufacturing flaws" could be considered as such an
abberation.  ANY unintended behavior can be considered to take the
machine out of spec within the framework OF that spec.  Thus, if the
issue of termination on the 3000 is intended to correct for an unintended
impedence matching problem (and this is completely supposition, there was
no information in the referred bulletin as to WHY they insisted on not
removing the terminators), the unintended impedence matching problem is
the abberation, the driving force that takes these 3000s out of spec.

>> >You've been lucky, I have also used non-standard termination schemes on it
>> >and got away with it until more/newer/faster devices were added, then had
>>
>> "There you go again."  I say again: I've had these "new fast drives" on
>> my system with no problems.  In fact, I managed to mount ONE 2 gigger as
>> an MSDOS disk AND transfer over 500 megs of source code to it, without
>> error.  Perhaps I'm doing something wrong...

>I don't doubt you, and in the end, as I'm sure you know well, it's what
>works that's important.  Then again, as someone else pointed out, people
>have slightly different ideas about what "reliable" means.  I define it as
>being able to run almost continous transfers for hours or days at a time
>with no errors or problems.

Would running the system 24 hours a day for years without break as a BBS
be considered sufficient punishment? :-)

>Obviously, and there is no doubt the desktop service manual left something
>to be desired, at least the ones that were available up here.  I bought
>them at various times from when they first came out to just before C= died,
>and always got the same one.  The 3000T's manual is much better.

Bummer!  That more or less means to me that the schematic in the back of
my 3000 manual is every bit as accurate as any other... it's a shame that
they didn't rev the manual.  It's times like this that I regret not
bribing the techos at one of our local stores to copy the things and pass
them to me.

>> have problems with tape, as that's my backup medium.  EMC, Telephony,
>> SCSI.  The dark words of Magic in the electronics industry :-)

>ROTFM!  From what the software guys that write CD drivers tell me, they are
>their worst nightmare, as every time a new model comes out they seem to
>twiddle with the firmware and format of the SCSI commands.  My old Archive
>tape works fine as well, but some people seem to have fun with their DAT
>drives.  There again, speed may be a determining factor.  TTYL

Yeppers.  If anyone has a question as to the validity of specs vs the
resulting hardware, one has to look no further than the current modem
market.  Now THERE is a field I'd hate to work in...